Resolve i18next-cli bin via module resolution for pnpm compatibility - #2
Merged
Conversation
Replaces spawnSync('i18next-cli', ...) with a node call to the binary
resolved via createRequire(import.meta.url). This ensures i18next-cli
is found relative to i18n-linter's own node_modules rather than relying
on it being hoisted to the consumer's root node_modules/.bin, which
breaks under pnpm's strict dependency isolation.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When using
@geomatico/i18n-linterin pnpm-managed projects, the linter would fail silently because it internally callsspawnSync('i18next-cli', ...), which looks up the binary via PATH (i.e. the consumer project'snode_modules/.bin).pnpm's strict dependency isolation prevents transitive packages from being hoisted to the root
node_modules/.bin. Sincei18next-cliis a dependency ofi18n-linterand not of the consumer project, pnpm does not expose it there.The symptom was the bundle sync check exiting with code 1 without showing any key diff, because the
i18next-cliprocess never actually started.Solution
Instead of relying on PATH, the absolute path to the
i18next-clibinary is resolved usingcreateRequire(import.meta.url), which resolves relative toi18n-linter's own location (its ownnode_modules). It is then launched viaprocess.execPath(the same running Node.js process).This works correctly with both npm and pnpm, and consumer projects no longer need to declare
i18next-clias a direct dependency.